세미프로젝트1_03_대시보드와 DB 마이그레이션

GitHub: tricrawl

시각화 준비

기간이 정말 짧았다. 남은 시간도 많지 않았다. 그래서 이제는 크롤링한 데이터를 대시보드로 보여준 뒤 거기에 최소한의 인텔리전스를 붙이는 쪽으로 목표를 좁히기로 했다.

기본 뼈대는 내가 이미 잡아놓은 상태였으니 대시보드 구축은 팀장이 맡기로 했다. 팀장은 Apache Superset을 쓰겠다고 했는데 내 눈에는 이 정도 규모의 프로젝트에 Superset은 조금 과해 보였다. 무겁고 설정도 복잡한 편이다. 커스터마이징이나 확장도 생각보다 자유롭지 않다. 지금은 시각화만 하면 되지만 나중에 대시보드를 더 손보거나 외부 API 연결 같은 걸 붙이려 하면 분명 제약이 생길 것 같았다.

내 생각에는 Grafana가 더 맞았다. 가볍고 데이터소스 연결이 유연하다. Prometheus나 PostgreSQL 같은 소스도 플러그인 하나로 바로 물릴 수 있다. 알림 기능도 기본으로 들어가 있다. 대시보드 커스터마이징도 JSON 모델 기반이라 확장하기 편하다. 커뮤니티가 커서 막혔을 때 자료를 찾기도 쉽다.

그래도 맡겼으면 믿어야 한다. 내가 다른 선택지를 더 낫다고 생각하더라도 그 선택을 끝까지 반대만 하는 건 협업이 아니다. 확장성 문제가 나중에 터지면 그때 가서 해결하면 된다. 지금 규모에서는 당장 큰 문제가 생길 가능성도 높지 않았다.

나머지 팀원들은 대시보드에 붙일 인텔리전스를 어떻게 구성할지 각자 정리해오기로 했다. 키워드 분석을 할지 위협 수준 분류를 할지 트렌드 시각화를 할지 먼저 방향이 나와야 대시보드 설계도 거기에 맞출 수 있기 때문이다.

나는 그것과 더불어 DB를 갈아엎기로 했다.

json에서 Supabase로

지금까지는 크롤링 데이터를 json 기반 로컬 DB에 저장하고 있었다. 스키마 고민 없이 딕셔너리 만들어서 dump하면 끝이니 프로토타이핑에는 분명 편하다.

하지만 이제 팀원 간 데이터 공유나 대시보드 연결을 생각해야 하니 DB 마이그레이션은 당연한 수순이었다.
자주 쓰던 Supabase로 마이그레이션하기로 했다.
PostgreSQL 기반이라 복잡한 쿼리도 자유롭게 날릴 수 있고 REST API가 자동으로 생성되니까 대시보드에서 바로 물리기 좋다.

문제는 그다음 리팩토링이었다. 프로토타이핑 단계에서 json 파일을 직접 읽고 쓰던 부분을 전부 수정해야 했다. 스토리지 레이어를 따로 빼두긴 했지만 그래도 손봐야 할 곳이 적지 않았다. 크롤러의 파이프라인 출력부터 데이터 조회 로직까지 스키마를 새로 설계했다. 기존 json 데이터도 변환 스크립트로 옮겨가며 하나씩 정리했다.

Supabase에 데이터가 올라가고 나니 대시보드에서 바로 끌어다 쓸 수 있게 됐다. 그 흐름으로 대시보드 구축까지 마무리됐다. 실시간으로 크롤링 현황이 갱신되는 것도 직접 확인할 수 있었다.

지금 돌아보면 이 작업은 프로젝트 초반에 들어가는 게 더 좋았을 수도 있다. 다만 당시에는 내가 아키텍처를 사실상 혼자 맡게 될 줄도 몰랐다. 시간도 부족했다. 무엇보다 프로토타이핑 속도가 먼저였으니 어쩔 수 없는 선택이었다.

결과적으로 큰 문제 없이 넘어가긴 했다. 그래도 다음에는 가능하면 초반부터 운영 DB를 깔고 가는 편이 더 낫겠다는 생각이 들었다.